We're having exact same issue

HCL Notes/Domino 8.5 Forum (includes Notes Traveler)

Subject:

Nigel,

Nasty problem, in that, as best as we could ascertain, its rare (yours is the only other incident I've seen on the internets).

Classic good news/bad news situation: We know _exactly_ whats going on, but we've no clue as to the root cause or how to fix it.

Let me tell you what we've found so far.

The error message you're seeing is in fact an authentication challenge (the login form) coming from the server to your Calendar client. Of course it looks nothing like an iCal feed and thus promptly fails.

Of course, your agent doesnt require authentication and ACL isnt an issue.

The reason that form comes up (or, rather, gets sent) we think is because Calendar client sends a basic authentication token/header (we've confirmed that by sniffing http traffic) as part of HTTP iCal GET request.

If you were to go to your personal NAB, advanced configuration, you'll see that for each iCal subscription there exists an Account document, containing all the information required to connect to the feed, including a name and a password, prefilled with the literal values "com.ibm.rcp.navigator.emptyusername" and "com.ibm.rcp.navigator.emptypassword" (to see the password, change field type to "Text" in designer).

These are the name and password used by Notes Calendar to create a basic authentication http header token. We have also confirmed that by sniffing and decoding the actual base64 value of that header.

Removing (blanking out) the password seems to completely suppress basic authentication token, subsequently "fixing" the problem.

Providing a valid username and password into the Account document, also appears to reliably fix the problem.

In SOME instances, and we couldnt so far find any pattern to that, Notes Calendar does NOT submit basic authentication token, and thus this problem isnt observed at all. This seems to be per-iCal-URL specific. Once a URL becomes "cleared" the Calendar no longer sends basic authentication token with it. Using that same URL in another Account document continues to "work" (that is to say, not send BAuth), yes that same URL if used on another workstation might fail.

This seems to suggest some sort of a caching or cookie type situation, but thats a pure speculation at this point, we're continuing to investigate this angle.

We've contacted IBM about this problem, they're looking into it. Some of this incident they've been able to confirm, but not all. Which makes it difficult to get them to escalate the issue.

This is about as far as we've been able to get.

Rouslan

Feedback response number WEBB7VPTBC created by ~Naomi Eknimarader on 09/08/2009